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ABSTRACT 

The purpose of the feasib5-lity study is to establish an 
automated data base system for Naval Electronics Engineering 
Center, Vallejo, California, The three divisions, namely, the 
financial, procurement and program manager's divisions, were 
analyzed as a separate entity by taking tlieir present methods 
of operation and determining which methods lend themselves to 
automation and propose a conceptual EDP system to handle the 
new data structure. After combining the applications of each 
division, a file design structure along with the associated 
hardware equipment and recommendations for further evaluating 
the overall performance of the system were supplied for NAVELEX. 
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I . BACKGROUND AND GENE)l/^>L PROBLEM STATEMENT 



The Naval Electronies Systems Engineering Center (hereafter 
referred to as NAVELEX) , Vallejo, California is tasked with the 
mission of providing eleetronics material support for eleetronic 
systems and individual equipment onboard ships and government 
field activities as assigned by the Naval Electronics Systems Com- 
mand. The majority of work performed on these electronic pieces 
of equipment is aecomplished by reimbursable work (e.g. the spon- 
soring activity of the particular ship or field activity sends an 
allocation of money for the v;ork that NAVELEX is to perform). Thus, 
there is no operating budget from appropriated funds to sustain 
their operation, funding being provided only from the various spon- 
soring activities. Though NAVELEX fias an aeeounting section for 
internal budgeting, the authorizing aeeounting activity (AM) for 
reporting N/\VELEX’s budget to higher authority is the responsibility 
of NSC Oakland. In addition, NSC Oakland is responsible for the 
eontracting of items with a value over $250. 

To assist the coirimonding officer in accomplishing the above 
stated mission is tlie task of the Planning and Program Management 
and Engineering departments respectively. The Planning and Program 
Management department responsibilities include advance planning on 
major task assignments, financiaJ. management and material management 
for all elements of the command and the command itself, and for tlie 
planning I'equired for the development and support of budget, long 
rajige , emergency and oLfier C(j;a'nand plans. These responsibilities 
and tasks are furtlier divided among three divisions. Tliese divisions 
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presently conduct their business without the aid of automation and 
are the subject of the feasibility study presented later in the 
paper. The Engineering department is responsible for the teclmical 
design, development and systems engineering on all task assignments 
and for the maintenance of plan files and for library and reproduc- 
tion services. The Engineering department was not considered in 
the feasibility study because it was determined in the preliminary 
investigation that computer termina2.s already existed as an aid to 
attaining its goal. The only problem with the system as it now 
exists is that there is no hardcopy capability. All data is input 
on a display terminal to the computer facility at Lawrenee Berkley 
Laboratories (LBL) and the computer printout is mailed to NAVTILEX. 

If a telephone line hook-up was established between LBL’s eomputer 
and a line printer at NAVELEX, the problem of meeting the time con- 
straints imposed by the different task projects would be satisfied. 

NAVELEX ’s two departments were faced with the problem of improv- 
ing their response time and thereby increase their effectiveness in 
the areas of material status for all assigned tasks, various account- 
ability reports, and for the maintenance of plan files. To determine 
what the impact of automating some of their present techniques would 
liave in solving th.ei r problem, a feasibility study was conducted. 

The study was restricted in tlie sense that any computerized system 
conceived would have to be operated by in-liouse personnel due to a 
government freeze on hix'ing. Thi.s caused additional factors to be 
eonsidcx'cd. The pex'sonnel selected to operate the system would have 
to be x^etx’aincd. The impact this retraining would have on tlic opex'- 
ntion of the system by switcliing from a manual opoi^ation to a mech- 
anized operation must be considered. These factors are not discussed 
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in the* thesis but are mer-ely mentioned to acquaint the manager 
with the possible pitfalls that lie ahead. 

Since no generally accepted procedure exists for determining 
what steps to follow in conducting a feasibility study, tlie 
choice of steps selected for each division in the Program and 
Planning Management department was to determine the required, 
reports that had to be generated by their present methods of 
oijeration, what methods lend themselves to automation and to 
produce an electronic data processing system (EDP) to handle the 
new automated techniques. Chapter two discusses the financial 
division. Chapter three describes the procurement division and 
Chapter four discusses the operation of tiie program manager’s 
division. Chapter five combines al3 three divisions in the anal- 
ysis of file organizations and produces a conceptual system for 
the Planning and Program Management department. In addition, 
recommendations are presented for further evaluation of the overall 
effectiveness of the system. 
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II. FINANCIAL DIVISION 



The financial division is responsible for preparing financial 
reports for the procurement division and for their submission to 
the authorizing accounting activity (AAA) , NSC Oakland, and for 
supervising timekeeping and payroll opertions. The following 
sections all discuss the two functions of the financial division 
namely, payrolJs and contracts. 

A. PAYROLL OPERATION 

The present method of handling payrolls consists of each shop 
center submitting a weekly worksheet to the financial payroll 
section that contains all the hours earned for that week including 
leave hours, sick hours, and assignment to temporary additional 
duty of their personnel. (Presently there are 790 employees 
assigned to NAVELEX) . Once in the financial division, two person- 
nel are assigned co transcribe the hours from the workslieet onto 
time cards and to validate any overtime. Overtime must be 
validated because salaried employees are not allowed overtime 
whereas liourly employees are allowed overage. This normally takes 
two working days before the time cards are routed to the account- 
ing section. The accounting section deducts the total dollar amount 
that tlie employee worked on a particular job order (at anytime 
there are at least 800 job orders outstanding) from the balance of 
the allotted dollars assigned to that job order. If tlie employee 
worked on a number of different job orders dui'ing the week, it is 
possible Llia t liis time cai'd would liave to be j)rocessed by t\^;o or 



11 



more accountants, since each accountant is responsible for only 
a fraction of the job orders that the financial division has out- 
standing. After all the time cards have been verified and posted 
to the accounting ledgers, they are> sent to NSC Oakland where 
they are then keypunched and listed onto tv/o magnetic tapes. One 
tape is retained by NSC Oakland to update their accounting records 
for reporting to higher authority since they are the designated 
accounting activity for NAVELEX, Vallejo. The second tape is 
forv/arded to the Regional Disbursing Center at Treasure Island 
where the employees' checks are actually printed. After all of 
the checks have been printed, a designated person from the 
financial division receipts for the checks and issues them to the 
various shop centers. This entire cycle is then X'epeatcd for the 
next vtfcek's worksheet. 

The problem that the financial division has with the above 
procedure is that of getting the time cards to Oakland in a 
timely fashion; in effect they are faced with improving their 
response- time while at the same time retaining sofne semblance 
of in-house accountability control. The problem of timely report- 
ing is caused by the nature of work performed by the employees. 

One employee may work on as many as five different job orders dur- 
ing the week thereby requiring his time card to be processed by 
two or more accounting personnel. This can cause a delay of two 
additional wox'k days before the total package of time cards are 
ready for submission to NSC Oakland. 

Analysis For A Conceptual EDP System 

The realization of an improved method of solving the dileiiuna 
that faces NAVELEX Vallejo required an evaluation of tlicir input. 
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data base, output and processing requirements. Input requirements 
could encompass a large area, but since this portion of the study 
was concerned with reviewing the payroll operation, the only 
areas that vjere considered for implementation in the computer 
system were the media, frequency of input, format of the input, 
and the type of transactions. The data base requii^ements considered 
the list of data elements including whether the elements were 
alphabetic, numeric or alphanumeric, indexing the entry into the 
data base, and the format of the data base. In regard to out- 
put requirements, tlie study considered the output media, the 
retrieval mode, format, and the output descriptors. Lastly, the 
processing requirements analyzed consist of the type of arithmetic 
operations required. The different operations required to get 
useful and meaningful output would consist of searching, sorting 
and editing. 

To formulate the input requirements, it was determined that 
all the time cards had to be processed at the end of each week and 
further that the most important information (as far as the account- 
ing section is concerned) is the dollar amount and number of hours 
credited to the employee while working on a particular job oi’der. 

In order to incorporate these two requirements, it was decided to 
use a batch schedule to update the master file'. and to run the 
required weekly update. The decision to employ a batch system 
vice a time sharing system as based on the fact that the employee's 
work sheet is only completed at tlie end of the week, thus preclud- 
ing any daily update to the file. The input media used consists 
of punched cards, which giv'cs tlie flexibility of liaving a direct 
visual copy of wliat vvfas input into the system in case the system 
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is down or that an error is deteeted. The input format, sJiown 
in figure 1, avoids having to input the entire record for each 
update. The type of transactions involved would be the changing 
of fields (e.g.. increasing Lhe hourly rate field if an 
employee received a raise or deleting entire records in the 
case that an employee was dropped from employment) . Also, an 
option was left to increase the size of the master file. This 
option satisfied the addition requirement of the input. 
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NUMBER 
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NAME 


NUMBER 









DATA INPUT 
Figure 1 



Tlie data base had to be structured so that pertinent 
information required by the accounting section eould be readily 
attainable. This was accomplished by having two data files 
that arc merged forming a "Payroll" file. One data file is 
called the "Dictionary" file which consists of the following 
data elements; employees’ name arranged in alphabetic order, 
social security number of the employee, and tlie hourly rate of 
pay if the employee is an hourly worker or the salary rate if the 
employee is salaried. The second data file is called tlie "Money 
Order" file v^7hose composition is job order number, dollars 
alloeaLed (whicii is tlic total dollars allocated for tliat job) , 



number of hours worked, and the social security number of the 
employees who worked on that particular job order. These two 
files are then merged to produee a master file called a 
"Payroll" file. The format for these data structures is shown 
in figure 2. It is obvious that the "Payroll" file (see 
figure 2) must consist of the follovjing data elements: name, 
social security namber, number of hours worked and the rate of 
pay, since this is the information that NSC Oakland requires for 
aceounting purposes. The contents of all tlie data files are both 
numeric and alphanumeric. 

The output information required by the accounting section 
must be in a readable and usable form. The simplest media 
for obtaining tills output is to have a hard copy capability 
that is supplied by a low-speed printer. A lov;-speed printer 
was decided upon vice a medium or high speed printer because of 
the cost involved, since the output does not have to be retrieved 
rapidly. A likely output format would key on the job order 
number field listing the job order in sequential order and within 
this job order an alphabetical ordering of the employees' names, 
with the number of hours eaeh employee worked. A sample output 
listing is given in figure 3. There are various options for 
outputting the data. As mentioned earlier one report would be 
in job order sequence and another by alphabetical sequence of the 
employees' name. An example of tills report is shown in figure 4. 
The output retrieval mode would have to be by batch keying on 
multiple descriptors. 
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FINANCIAL DIVISION FILES 
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Tlie processing requirements must include tlie capability of 
sorting records either by name, social security number, job order- 
number, etc. Also, if any changes are made to a record it is 
desirable that only selected fields be edited without having to 
input a complete new record every time a cliange is made. There- 
fore this feature must be added to the system. The search of the 
file is done sequentially. 

Using the above analysis, a conceptual EDP system is 
illustrated in figure 5. A detailed analysis of the file struc- 
ture required to implement the system is given in Chapter five. 
This oiaeration would be based on having the shop center supply a 
person to validate all overtime and leave of personnel assigned 
to their centers. This person would keypunch the time cards 
and submj.t them to the computer. The computer would produce a 
magnetic tape for NSC Oakland and a listing printout for the 
financial division’s in-house use (see figure 6). This automated 
procedure would eliminate at least four working days from the 
present manual processing time. 

To handle this procedure, the system would not require a 
large memory capacity so a minicomputer with a capability of add- 
on memory could be used. Since NAVELEX is concerned with getting 
the magnetic tape to Oakland as soon as possible (and at the same 
time retaining a hard copy to validate internal control), a 
medium speed magnetic tape unit for rapidly producing tapes, a 
low-speed offline printer for producing a hard copy to be 
retained by the financial section and a cai'd reader to read the 
input arc required. 
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FINANCIAL DIVISION 
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FINANCIAL DIVISION 



B. CONTF^CTS 



Contracts fall into two basic categories. Indefinite Delivery 
and One Time Purchase contracts. In this chapter Indefinite 
Delivery will be discussed because it is the only type of contract 
that the financial section handles directly. 

Indefinite Delivery contracts are contracts that have already 
been established with a contractor due to some previous demand 
experience or request. Once tFie decision is made by the project 
manager that contract support is required, the financial manage- 
ment division is responsible for administering financial control 
of the contract request which consists of assigning a requisition 
number and obligating funds against that job order and for sending 
the obligation to NSC Oakland, and for effecting purchase action 
which calls for the contractor to give a dollar amount estim.ate 
for the requested material or services. 

The problem that the financial section faces is to assure 
that reported outstanding obligations are, in fact, outstanding 
and if the material or services have been received to make sure 
that receipts are posted in a timely fashion so that payment to 
contractors can be effected. 

Analysis For A Conceptual EDP System 
The above problem cannot be solved by the financial division 
alone because they depend on the shop centers to provide signed 
receipt copies to effect payment. In addition, the financial 
division relies on the procurement and planning division to 
provide the status of outstanding requisitions. Since tlie require- 
ments for tlic conceptual EDP system are very similar to the EDP 
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requirements for tlie eontraet portion of the proeurement and 
planning division, an alaiysis for t)ie finaneial division will 
be delayed and eombined in tlie analysis of the proeurement seetion 
of eontraets diseussion. 

III. MANAGEMENT ANALYSIS AND ADVANCE PLANNING DIVISION 

The management analysis and advanee planning division will be 
hereafter referred to as the proeurement division sinee this is 
the only portion of the operation that a request for a feasibility 
study was made. The proeurement division has the responsibilities 
for the establishment of NAVELEX’s annual Indefinite Delivery 
eontraets, for initiating One Time Purchase contracts through the 
appropriate procurement contracting office, NSC Oakland, and for 
the surveillance and administration of the contract after award. 
The remaining paragraphs of the chapter will discuss the present 
method of operation, the problems associated with the method and 
offer an alternative approach to enlarge the overall effectiveness 
of the division's operation. 

A. PROCUREMENT DIVISION OPERATION 

The basic decision of whetlier contractor support is required 
on a particular job order rests \tfith the shop center responsible 
for the work associated with the job order. Wiare contractor 
support is desired, or required, a contracting specialist is 
available in the procurement division to pr'ovide contracting 
advice. The contracting specialist reviews the request from the 
shop center and fotvv’ards the document to the financial division 
where it is verified that funds are either available or exhausted 
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for the job order. If funds are available after verification the 
eontraeting specialist prepares the neeessary proeurement request 
to the contracting office (usually, NSC Oakland) if the request 
is for a One Time Purchase. If the request can be filled with 
an Indefinite Delivery contract no assistance from NSC Oakland is 
required. IVlien the request is forwarded to NSC Oakland, the 
contracting specialist must then await a reply from the contracting 
office before any action can be taken. However, the procurement 
division's contracting specialist maintains liaison with the 
contracting office as required to assure any questions that may 
arise arc answered and to assist the contracting officer through- 
out the preawarding process. When the contract has been awarded, 
copies are provided to the shop centers concerned to assure 
consistency with the original requirements. When changes are 
required to an existing contract, the shop center will initiate t}ie 
request and it will be routed through the program manager, procure- 
ment division, financial division for accounting purposes, and 
finally to the contracting office. If immediate changes are re- 
quired, the program manager is notified. He works with the 
eontraeting specialist who advises the applicable contracting 
officer to inform him of the immediate action required. With the 
contracting officer's approval, the change is then accomplished 
and the paper work follows. In the case of Indefinite Delivery con- 
tracts, the contracting specialist goes directly to the contractor 
with the request and monitors the request until the material or 
services arc delivered. After the receipt of the materials, the 
contracting specialist determines the quality and acceptability of 
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the materials and passes the information to the financial division 
so that the contractor may be paid. 

The primary problem facing the procurement division is the 
need to shorten the response time from the shop center's initial 
request for contractual services until the contracted material is 
received. An additional drawback is the inability of NAVELEX to 
contract directly (witliout going througli the contracting office, 
NSC Oakland) any One Time Purchase conti'act with a dollar amount 
exceeding $250. This factor is a substantial restriction for 
NAVELEX 's operation because most of the contract requests arc in 
the range of fifty thousand dollars. 

Unless NAVELEX is authorized a larger dollar ceiling there 
will always be a significant time delay. This delay occurs 
because the document requesting contract support must be mailed 
to NSC Oakland and normally there will be additional delays 
because of constant telephone communications with the contracting 
officer at Oakland trying to obtain information from the contract- 
ing specieilist. The only portion of the problem that NAVELEX can 
influence is the currency of the Indefinite DeJ.ivery contract and 
of providing current status of One Time Purchase contracts. 

Conceptual EDP System For Procurement Division 

The purpose of the feasibility study is to investigate 
alternative metliods to minimize the response time from the initial 
request for contractoi’ support until the receipt of the material 
from the contractor. As noted from the above operation, the 
only influence tliat the procurement division can bring to bear 
on the problem is to validate tfie currency of the annual 
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Indefinite Delivery contracts so ns to alleviate the necessity 
for renegotiating elapsed contracts and for maintaining current 
status on the One Time Purchase contracts. These two areas will 
be discussed in an effort to offer an alternative automated approach 
to the present method of operation. The following discussion 
describes the input, data base, processing and output requirements 
of the two areas and propose an EDP system to satisfy the require- 
ments. The input analysis considered the frequency of input, 
input media, format of the input and the type of transactions 
processed. The data base requirements considered the list of 
data elements, including whether the elements are alphabetic, 
numeric or alphanumeric emd the format of the data base. In regard 
to tlie processing requirements, the study considered the type of 
operations required: searching, sorting and editing. Lastly, the 
output requirements consisted of the output media, format and the 
frequency of the output. 

In the input anal-ysis phase it was determined that there are 
two types of input v\7hich the contracting specialist must input to 
the system in meeting his responsibilities. The first input type 
is the maintenance and updating of each Indefinite Delivery con- 
tract. It was decided to use a timesharing scliedulc vice a batch 
schedule because any request for an Indefinite Delivery contract 
update occurs on demand and not all contracts require updating. 

The input media would consist of terminal displays which give the 
flexibility of rapid update of a record. The input format shown 
in figure 7 avoids having to display the entire record each time 
selected fields liavc to be updL Led . The transactions involved are 
the manipulations of selected field that the contracting specialist 
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may want to change is the "dollar amount" field. The second input 
requirement is the maintenance of the current status of One Time 
Purchase contracts. It is obvious that this function must occur 
on demand because different contractors provide status only on 
their contracts. Since there is no guarantee that all the status 
will be received simultaneously, it v\?as decided that a time shar- 
ing demand input schedule v/ould satisfy this requirement and the 
input media would be terminal display CRT units. The format of 
the input is similar to the format of figure 7. Normally, the 
only fields that would change are the estimated delivery date (EDO) 
and status fields. 



-CONTRACT 


FIELD TO 


FIELD TO 


NUMBER 


BE UPDATED 


BE UPDATED 



TERMINAL DATA INPUT 
Figure 7 

Tlie data base must be structured so that useful aixl 
understandable information required by the procurement division 
can be readily obtained. This is accomplished in two v\?ays. For 
Indefinite Delivery contracts, the data base required is called 
the "Annual ID Contract" fi.le and it’s composition is Indefinite 
Delivery Contracts arranged in contract number order that are 
active in the current fiscal year. The format of tlie file is 
illustrated in figure 8 and tlic list of data elements contains 
the contract number, job order number, material (jr service 
provided, dollar amount allocated for the contract number and tlie 
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date the contract elapses. The contents of the fields in the file 
are both numeric and alphanumeric. For One Time Purchase contract 
status, the data base file is called the ”OTP" contract file and 
consists of the following data elements; contract number, brief 
description of the requirements, status, job order number and dol- 
lar amount allocated. It’s composition is shown in figure 9 and 
the contents of the file are alphanumeric and numeric. 

The processing requirements must include the capability of 
sorting records by contract number, dollar amount, estimated 
delivery date, etc. In addition the ability to edit selected 
fields without displaying the entire record must be built into the 
system. The searching of the files is accomplished by direct 
access . 

The output requii'cd by the procurement division must be in an 
easy- to-read form. There are t\\?o media for accomplishing this 
form. One is to have the display terminal output the status that 
management or the shop center requii'es immediately, however there 
is no hard copy capability with this media. A second media that 
supplies a hard copy capability would be a low or medium speed 
printer. There are various options for outputting the data; an 
example output for Indefinite Delivery Contracts is shown in 
figure 10. This output would list all contracts that would elapse 
in a specified number of days in contract number sequence. For 
One Time Purchase Contracts the format of the output is shown in 
figure 11 and vs/ould key on the dollar amount field and list only 
those contracts over a certain dollar amount. This would be 
valuable information if the prccurement division was comtemplating 
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cancGlling some of the high value non-eritieal eontraet items in 
order to reprogram the money to order highly eritieal items. 

To handle the above requirements a eoneeptual EDP system is 
shown in figure 12. The file organization strueture needed to 
implement this system will be deseribed in ehapter five. Tlie sys- 
tem would Gonsist of a CRT display terminal, a low speed printer 
for allowing a hard eopy eapability, offline disk storage to 
rapidly bring files online for immediate status information and 
a minieomputer to sequenee the operations of the other peripheral 
deviees . 
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Figure 12 



IV. PROGRAM MAMGI'RS DIVISION 



For every work request that NAVKLEX Vallejo receives from a 
sponsoring activity, a program manager or project manager is as- 
signed by NAVELEX to monitor the V’ork request through to completion. 
The duties of a program manager include serving as the contact 
point for the receipt, coordination and correlation of customer 
program requirem.ents , ensuring timely and efficient completion of 
task assignments, advising management of potential difficulties 
and delays in critical task assignments, determining time and cost 
trade-offs in meeting customer requirements, monitoring the prog- 
ress of all assigned projects and preparing the necessary reports 
to management and directing distribution of funds for the accom- 
plishment of assigned program tasks. The remaining portions of 
the chapter describe the program managers' present method of 
accomplishing his assigned duties and offer an alternative auto- 
mated approach to improve the overall effectiveness of the oper- 
ation. 

A. PROGRAM M;\NAGER'S OPERATION 

Wlien a request for servicing some type of equipment is received 
from a sponsoring activity, NAVELEX assigns a program manager with 
expertise in the operation of that equipment to be in charge of 
the project. Once the program manager is assigned he must decide 
on the numbci' of steps that are needed to complete the work re- 
quest. Each step must be assigned a job oi’der and given to a shop 
center wJiere the shop center analyzes tlie number of personnel it 



34 



will have to supply, since the shop center actually does the work 
on tJie step. Any materials or services that the shop centers re- 
quire are referred to the program manager who in turn has to con- 
sult with the procurement section to ascertain whether a contract 
exists or if bids are needed to establish a new contract. Deter- 
mining that the contract exists (or after awarding new contracts) 
tlie program manager must wait for the status of tlie contracts. 

In some cases the materials for some of the steps will be received 
before other steps which could effect the completion of succeeding 
steps. The program manager must constantly be cognizant of the 
bottleneck that could occur. If the situation arises v;here the 
dollar cimount of the required materials or services outweighs the 
dollar amount of the job order, the program manager must determine 
time and cost trade-offs in meeting the sponsoring activity’s 
requirements. The alternatives available to the program manager 
are to request that the sponsoring activity increase the dollar 
allocation for the work request or to attempt to refurbish some 
of their .old equipment to conserve money. If the work proceeds 
as scheduled, the material will be receipted for by the shop center 
and the paperwork passed on to the program manager who must pro- 
vide a copy to the financial section so that the contractor can 
be paid. 

The problem that the program manager faces with the abov'e 
operation is to get status in a timely fashion of all outstanding 
contracts that may necessitate changing priorities. Presently, 
this is done manually be calling either the contractor or NSC 
Oakland for the current status of contracts. This interrogation 
may take tv\?o or tliree liours if tlie telephone lines are busy or if 
NSC Oakland has to quei^y their computer because status lias a low 
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priority in their computer operation. When this status is received, 
it must be sent to the management personnel section in an under- 
standable format so that time and tradc-off considerations can be 
weighed and a decision reached on liov\/ to complete the assigned 
work request. 



Analysis Of Conceptual EDP System 

To alleviate or minimize the problem associated with the 
above operation an analysis of the present techniques of opera- 
tion lead to the conclusion that the operation could indeed be 
automated. The succeeding paragraphs will analyze individually 
the input, processing, data base and output requirements, respect- 
ively. The components of the input requirements include the fre- 
quency of input, content of the input, i.e. wlietlier the input is 
alphabetic, numeric or alphanumeric, time of input, input mode, 
format and tlie types of transactions. The processing requirements 
consist of searching, method of rctrievcil, editing and sorting. 

The data base requirements consist of the list of data elements, 
format of the data base and the data structure. Finally, the 
output requirements consists of the format, output mode, frequency 
of tlie output and the content of the output. 

In the input requirement phase of the analysis, the data that 
the program manager must have to assist him in meeting his respon- 
sibilities consists of t\s7o types of input. The first type of 
input is tlie establishment of a i^ccox’d called the "Contract” 
record for each contract number (sec figure 13) . At the very 
minimum, the amount of information needed for creating the input 
foi' tlie "Contract" record is the contract number, a brief identi- 
fication of tlie materials or services required and the dollar 



amount allocated. The content of the input is both alph.anumeric 
and numeric and the frequency of inputting this data is obviously 
on demand because awarding a contract to a bidder is directly 
related to the dollar amount of the bid. However, it is recommended 
that new ’’Contract" records only bo established at the end of 
NAVELEX’s daily operation and that it be accomplished as a batch 
process . 

The second type of input that the program manager must have 
at his disposal is the ability to query the "Contract" records for 
status (see figure 14) . The most important field to the program 
manager is the estimated delivery date (EDD) . The only input that 
must be supplied by the program manager is the contract number. 

The frequency of input is the same as the first type of input with 
the exception that the information must be supplied as soon as it 
is needed so that the input mode must be realtime CRT terminals. 

The only type of transactions applied in the input phase of the 
analysis are editing different fields of the associated records. 

The- components of the processing requirements must be capable 
of allowing the program manager the ability to selectively search 
for status on "Contract" records. A sequential search would not be 
feasible if many records were on file, therefore the solution would 
be to have the capability of direct access. Since the status of 
a contract is constantly changing until the material is actually 
receipted the option of being able to update the record is requii'cd. 
This updating would include tlie editing of eertain fields of the 
recox^d if the status is changed or if a substitute item is exchanged 
for the original material. The thii'd processing requii’ement is the 
capabili ty of de3.eting rccoreds from the file once tlie materials 
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CONTRACT DATA 




have been received. The retrieval mode for bringing records online 
would be direct access in order to speed up the computer time per 
request versus the slower sequential mode. The final requirement of 
sorting is a sequential sort keying on the contract number. 

The data base required to satisfy the input and processing 
required would consist of two files called the Contract file and 
the Name file. The "Contract" file which is made up of "Contraet" 
records has the composition of contraet number, dollar amo'unt 
alloeated, a brief identification of the major piece of equipment 
being refurbished and the date the contract was established. The 
"Name" file contains identification of the material needed in the 
renovation of the equipment, contract number, current status, 
job order number and the cost of purchase. These files are then 
merged to create a master file called the "P.M." file with the 
format for these data structures sliown in figure 15. The "P.M." 
file consists of the contract number, a listing of the materials 
ordered under the contract number, status, and the cost allocated 
for the material. 

The output information required by the program manager must 
be in a readable and usable form. There are two media for obtain- 
ing the required output. To keep management informed on the 
dollar cost and any delay in receiving materials, one type medium 
is to have a hard copy capability that is supplied by a line 
printer. This report would be presented to management on a weekly 
basis. An example output listing is given in figure 16 and would 
key on the contract number field listing the coiitract numbers in 
sequential order. To keep the program manager abreast of the 
changing status of materials ordered, the second medium that would 
be employed is a CRT display. Its format is similar to figure 17. 
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NAME OF MATERIAL: ELECTRICAL TRANSFORMER 
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Using the knowledge of the above analysis, a eoneeptual EDP 
system is depieted in figure 18. This operation would be based 
on only having the users trained in the operation of the CRT 
display. The file organizatinn assoeiated v^;ith this system will 
be diseussed in Chapter five. The system would require off-line 
storage versus loading magnetie tapes, it v;as deeided to liave the 
files stored on disk. A small minieomputer will be used to bring 
the monitor or supervisor program on-line (from magnetie tape) 
and to sequenee the other peripheral deviees. A medium or low 
speed printer is required to generate the weekly reports for 
management and a CRT display terminal would be used for ereating 
new "Contraet" reeords, editing files and deleting reeords . This 
would eliminate the need for a eard reader. 
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PROGRAM MANAGER DIVISION 



V. FILE ORGANIZATION & CONCEPTUAL EDP SYSTEM 



In the earlier analysis of chapters twOj three and four, each 
division's operation was treated as a separate entity and a 
conceptual EDP system was proposed for the various applications 
without regard to integrating the four basic components of 
systems analysis namely the processing mode, data base, file 
design and the applications required by the user. The triangular 
effect of these four components as they relate to the feasibility 
study is illustrated below: 



Processing Mode 



File Design 



1, 


Batch - 




1. 


Sequential 


2. 


Remote batch 




2. 


Indexed Sequential 


3. 


On-line retrieval/ 


/ data\ 


3. 


Random 




Batch update 


4. 


List Structure 


4. 


On-line retrieval/Update 


/ BASE \ 




a) Uncontrolled 








length 



b) Controlled 
length 

c) Inverted 



APPLICATIONS 



1 . Payroll 

2. Contract File Inquiry 

3. Contract File Update 



The remaining sections of this chapter will discuss the following 
items: 1) revievN? the data base files proposed for chapters two, 
three and four, 2) analyze the various processing modes mentioned 
above, 3) discuss the various file design considerations, 

4) review the applications of the throe divisions and determine a 
concep tioiKil system and S) provide criteria for evaluation of the 



system and make recommendations for further research in determining 
the overall effectiveness of the system. 

A. THE DATA BASE 

The data base proposed for the financial division consists of 
the "Payroll,” "Dictionary” and"Money" files. For the procurement 
division the files proposed consists of the "Annual I.D. Contract” 
and "O.T.P. Contract" files and finally the program managers 
division files consisted of the "Contract," "Name," and "P.M." 
files. The hierarchic data structure approach is used for the 
above mentioned files and is shown in figure 19 [Ref. 1 J. The 
superior record in the hierarchy is called a master record and an 
inferior record is called a detailed record. In addition, a 
detail of one record may be a master of another record. The net- 
work schematic of the hierarchic file structure is illustrated in 
figure 20. For each file in the figure, a list of the data elements 
associated with that file are included. From examiniation, it is 
conceivable that tlie "Annual I.D. Contract" file and the "O.T.P. 
Contract" file, even thougli each is a master record, may be merged 
into a single master file because they contain the same data 
elements with the exception of tlie elements, "Contract Elapsed 
Date" and "EDD." Thus, the new merged file would contain seven 
elements vice the twelve data elements that now exist. In addition, 
other common data elements are employee name, social security 
number, contract number, status, material required, job order' num- 
ber and dollar amount. Althougti it is not presently known what 
file design will be used, these data elements are candidates for 
maintaining in a Key Dix'cetory described in a siJjsequcnt section. 
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Record Name Type Master of Detail To Contents 



Hours worked. Pay earned, Employee’s name. 
Social security number 


Job order number. Contract numljer. Status, 
Contract elapse date. Dollar amount. Material 
or service 


Contract number. Job order number. Dollar amount. 
Current status. Description of req., EDD 


Contract number. Job order number. Date 
established. Equip. Identification, Dollar amount 


Material required. Contract number. Current 
status. Dollar amount. Job order number 


Contract number. Material required. Current 
status. Dollar amount. Job order number 


Employee’s name. Social security number 
Rate of pay. Code (S or ]-[) 


Job order number. Dollar amount. Number of hours 
v\/orked. Social security number 
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HIERARCHIC DATA STRUCTURE 
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B. THE PROCESSING MODE 



The different messing modes considered in the analysis 
consisted of batch, remote batch, on-line retrieval/batch ux^date 
and on-line retrieval/update. In the strict batch processing 
mode, users prepare their programs, punch them on some input media 
such as cards and then submit them to an operator for execution. 
User programs are input to the computer in batch . The operating 
system software would read one program at a time into the machine 
and execute it according to some predetermined discipline and 
write out the results on some output device such as a printer. 

The operator would retrieve the printed output and return it along 
with the input card deck to the user. Thus, the user’s only con- 
tact with the system is through a slot in the ADP section where 
he/she deposited cards and retrieved the output. This mode of 
operation is suitable for many types of production runs; i.e., 
processing against written and debugged programs that are used 
again and again. However, VN/ith this mode there is a time lag, or 
turnaround time, of anywhere from a couple of minutes to several 
days depending on the users distance from the EDP center and the 
computer center’s system characteristics. Therefore, if response 
time is a critical factor in the user’s requirements this mode of 
processing may not be adequate. 

Within a remote batch processing mode environment, the user is 
physically remote from the comx)uter facility. The user x^^'ovides 
requests from terminals to run certain production programs in the 
batch mode at the EDP center. The output may be printed at the 
remote location of tlie user or at the computer center. As far as 
the user is concerned he has made direct contac t 'v\/i th the central 
processing unit for his request. As far as the computer is 



concerned, however, the request is treated in the batch processing 
mode. The reason for this difference in concept is that the 
request, once it leaves the terminal, is put in a job queue and 
processed according to some determined servicing discipline. This 
mode of processing is desirable for a user that does not own or 
have a computer center dedicated to his work requests and the output 
generated is not required immediately. 

The on-line retrieval/batch update processing made consists 
of the user employing some on-line device such as a terminal to 
immediately seize the central processing unit and interrogate the 
data base directly. However, it any update to the data base is 
required, the user makes the request on the terminal, feeds the 
information to some off-line storage device (e.g., magnetic tape) 
and at the end of the day's operation this data is processed in a 
batch mode . This processing mode may be desirable if the usei' 
needs to retrieve thefiles on-line but file updating is not 
required as rapidly. 

Finally, the completely on-line retrieval/update processing mode 
allows the user to seize the central processingunit and hold it 
until the inquiry or update is complete. This type of processing 
is sometimes called processing in real time. Real-time 
processing implies that tlie computer receives data, processes it, 
and returns results quickly enough for these results to be utilized 
in the continuation of the task being conducted. Many operation 
don’t require an on-line update because the manager or supervisor 
is not going to be in a position to make an imjnediatc decision on 
the basis of the output generated, so a batch update would suffice. 
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C. TIE FILE DESIGN 



There are many options available for file design, but for the 
purpose of this study the file designs considered consisted of 
sequential, indexed sequential, random, and list structures witli 
emphasis on uncontrolled length, controlled length and inverted 
files . 

With a sequential file design, the logical and physical order 
of the records are the same. Generally, the records in a 
sequential file are in lexicographic order of the values in some 
particular field or fields within the records. The fields that 
determine the sequential order are called keys. For instance if 
the field "Name" was a key the file would be ordered alphabetically. 
If a key is used in searching a file, it is relatively easy and 
quick to retrieve a number of records in sequence or to determine 
if a particular record is present in the system by performing a 
sequential search on the file using the key. For applications that 
require the use of a magnetic tape, the sequential file design is 
the only option tliat is open to the user because the magnetic tape 
can only be searched using one key at a time. The major dis- 
advantage of a sequential file structure search lies j,n the fact 
that each and every record in the file must be examined if the 
search involves a field which is not the key for the file . 

With an indexed sequential file design, records are stoi'ed in 
sequential order as on magnetic tape. However, an indexed sequen- 
tial file design organization takes advantage of the cylinder 
structure of tlie particular direct access file to provide indexes 
tliat make it possible to locate a specific file record w’ith only 
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one seek delay. A two-level index is used. The first index is 
a eylinder index (e.g., a table eontaining the eontrol key of the 
las t reeord stored in eaeh eylinder as the argument and the 
eylinder number as the funetion of the table) and the seeond level 
index is the traek index (e.g., another table wliose arguments are 
the eontroJ. keys of the last reeord on eaeh traek and whose 
funetion values are the assoeiated traek addresses) . An example 
of an indexed sequential file is illustrated in figure 21. When 
a file is in use, tlie eylinder index is maintained in main memory. 
If it is desired to find a reeord in figure 21 eorresponding to the 
eontrol key 00S87, first, a table look-up on the eylinder index is 
performed with 00587 as tlie seareh argument, finding the first 
argument greater than or equal to 00587. Sinee 00587 is greater 
than 00475 and less than 00983 the reeord is determined to be in 
eylinder 003 . Thus a seek is performed on eylinder 003 and its 
first traek is read, plaeing the traek index for eylinder 003 in 
memory. Again a table look-up is performed using 00587 as the 
seareh ' argument . Tliis seareh reveals that the reeord is in traek 
03 of this eylinder, so one finds that the seeond reeord is tlie 
one that is desired. This whole proeedure eonsists of a table 
look-up, one file seek, a read, another table look-up, another 
recid, and examine the traek to find the reeord. The advantage of 
this file design is that tlie time to find a reeord is not as great 
as with a sequential file design beeause only one seek is performed 
and the time involved in table look-ups is small. The disadvantage 
with Lliis design involves the handling of additions to the file. 
Sinee the reeords are tiglitly paeked into the file traeks, there 
is no room for new reeords unless extra spaee is provided. 
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INDEX SEQUENTIAL 
FILE STRUCTURE 



Generally, list strueture file design teehniques fall into 
two classes: multiple threaded lists (controlled and uncontrolled 
length) and inverted lists. In a multiple threaded list 
(uncontrolled length), there is a directory that contains a list 
of keys. In addition to the key name and value, a link address 
whieh indicates the first record on the direet aeeess storage 
device (DASD) is also stored in the key field. The output of the 
key directory is a fixed length record eontaining the key/head of 
list address/list length. A sample multiple threaded list is 
shown in figure 22. The head of list address is represented 
symbolically as An, where n is a numeric representing a mass 
memory address. Reeords within the file area are represented as 
dots along the thread emanating from the output level of the key 
directory. Thus, the J list begins at address A3 and contains 
six reeords. As indicated in figure 22, the fourth record on the 
J list is also the second record of key T because of the list 
intersection. This 'record has not been labeled with an address 
in the figure because it is not a head of list record since the 
head of the T list is at All; ho^^?ever, there v^ould be a link 
address pointing to this record contained within the record at 
All. If, then, a query conjunetion JT were to be searched in 
this file, the Key Directory Decoder would decode both J and T and 
examine the respeetive list lengths at the output of the 
directory. Sinee tlie J list is shorter, eontaining six records as 
opposed to eight for tlie T list, the J list would be searched, 
thus requiring six random seai’clies within the file area. Each 
accessed record must be examir.ed in core for the joint oceurence 
of T. With this type of file design a DASD must be used l)ecause 
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MULTIPLE THREADED LIST STRUCTURE 
Figure 22 
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of the random searehes required. The greatest disadvantage of the 
multiple threaded list is that in order to respond to a eonjunction 
of terms like J interseetion T, it must aeeess from the DASD and 
transfer to eore all reeords on the shortest list for examination 
in the processor, even though the interseetion of these lists, 
whieh satisfies the query, may be much smaller (in the example, 
six reeords are queried for one interseeted record) . The 
principal advantages of the multiple list (uncontrolled length) 
file organization are programming simplicity and update flexibility. 
In the inverted list file organization system, all link 
addresses have been removed from the file area and appear instead 
at the output of the key directory. This will result in a 
considerably larger directory than the multilist system although 
the total memory usage is no greater because these same link 
addresses no longer appear within the file record. The lists are 
variable length reeords that must be maintained in a monotonie 
sequence for efficient logical manipulation. The seareh for the 
joint oecurrence of terms is accomplished by list interseetion 
witliin the directory and the conjunction of a nonnegated key with 
a negated key is accomplished by removing from the nonnegated 
key's list of addresses all those tliat appear on the negated list. 
Eaeh of the two described logical functions are greatly expedited 
if the list addresses are stored in monotonie sequence, since only 
a single pass tlirough the two lists is required. The principal 
advantages of the inverted list over the multilist file 
organization is that the list intersection or merge pi'oeess is 
considerably more efficient sirce it is performed on eompaet, 
sequenecd lists rather tlian requiring a random accession for each 
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record on the list. Also, it is a good file organization for 
data retrieval, especially wlien it is not known in advance what 
keys the user will require to process data. The disadvantages 
of the inverted list system are that a working or staging area is 
required in order to perform the logic processing and the list 
records, being variable length, should include some reserve if 
real-time updating is to be allowed. 

VVhen discussing the multilist (controlled length) , it should 
be noted that multiple lists (uncontrolled) and inverted file 
organization are special cases of multilists wliere the former has 
list control of infinity and the latter has list control of unity. 
Thus, controlled length multilists are actually partially 
inverted files. The special case of controlled length multilists 
considered in this study is the cellular partition file design. 

The basis of the cellular partition is to define logical cellular 
boundaries tliroughout the DASD medium into wliich the records may 
be placed accoi'ding to some predetermined storage strategy. A 
sample cellular multilist file organization is shown in figure 23 
with the predetermined length being tliree. Since the cell is 
part of the record address, the address notation Am.n/L is used 
wliere ”m" identifies the cell in which a given lists begins, 

"n" identifies the mass memory address and "L” identifies the 
length of the record. Consider the query JT. An examination of 
the output level of the dii’ectory sliows that list J contains sub- 
lists that arc wholly contained with Cells 0, 1, 2 and list 
lengths 3, 2 and 3; therefore, one cannot expect to find a 
conjunction of J and T in any cells that are not: contained witliin 
tlie cell intersection between the head of list addresses of J and T. 
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That is, list J contains a head of list address in Cell 0 buL list 
T does not; therefore, no interseetion of JT exists in Cell 0 he- 
eause list T does not appear in Cell 0. Similar reasoning applies 
to Cell 3. Therefore, the seareli on the conjunction JT would be 
limited to those sublists J and/or T contained only in Cells 1 and 
2; furthermore in Cell 1, either list J or T may be searched be- 
cause they are the same length however, in Cell 2 list J is pre- 
ferred because it has a length of 1 versus list T whose length is 
2. The search would issue an I/O command against both addresses 
in the J listing. The entire search would be effected in three 
random accession times rather than six. The advantages of this 
file design are that random access can overlap (if permitted by 
the DASD configuration) provided the "next records to bo accessed" 
are in different cells and the programming of this structure is 
no more difficult than the programming required for the multiple 
(tlireaded) list. 

D. APPLICATIONS 

A review of the applications of the financial division 
indicated that the payroll application was the only one that 
should be automated in the near future. This application con- 
sisted of updating the master payroll file weekly in order that 
the magnetic tape could bo sent to NSC Oakland. For this appli- 
cation a batch mode sliould be utilized because there is no re- 
quirement for frequent inquiries to the file nor is the speed of 
response time a critical factor. It is further recommended that 
the "MONEY" file (figure 2) be designed as a sequential file be- 
cause file access is generally for a group of records vice a 
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single reGord and these accessed records arc copied onto magnetie 
tape for submission to Oakland. 

The procurement division’s applications consisted of updating 
and demand query of certain fields of the ’’Annual I.D. Contract” 
and ’’O.T.P. Contraet” files. Since inquiry to these files is 
primarily on demand and then for only selected records, some con- 
figuration of an on-line random access file system is indicated. 

It is recommended that an on-line retrieval/bateh updating system 
be utilized for tliis application since the user will be interested 
in the current status of various records. If the records require 
updating the user would generally not be in a position to make an 
immediate decision on the update information, even if it was done 
on-line, hence a batch update mode is reeommended. Most of the 
fields of the ’’Annual I.D." and ’’O.T.P. Contract” files will not 
require key dictionaries but the keys that do require key dietion- 
aries will have to be detailed (e.g., the keys of the dollar amount 
field may be broken down for every one-hundred dollars) . Thus it 
seems obvious to use a fully inverted list for this reason. IIov;- 
ever, on closer inspection one finds that the disadvantages as- 
sociated with this file design as mentioned above would negate 
any advantage that existed with using an inverted file structure 
organization. Thus, the file design recommended is the multilis L 
(Cellular partition) , with this design the advantage of an inverted 
list exists without the problem of requiring additional work space 
as required with a fully inverLed list. 

Finally, tJie only application for the pi'ogram managers division 
that requires automation is demand inquiry of the ’’Conti'act” and 
’’Name” files. With this application, fast response time is 



60 



important, therefore, some on-line random access file system is 
required. Since the program manager’s division applieation is 
the same as the procurement division (with tlie exception of up- 
dating) it is reeommended that the same system be incorporated 
for the program manager’s division. 

The results of the analysis indicate that the system should 
operate in two modes. At the top level of operation, there is an 
on-line system communicating with user terminals and vice versa. 

At the lower level there is the batch system for updating records 
and files on a predetermined schedule arranged by NAVELEX. Two 
file design organizations are maintained namely, sequential and 
multilists (Cellular partitions). The system shown in figure 24 
encompasses all the hardware required to perform the applications 
of the three divisions into one system for NAXDLEX. 

E. EVALUATING CRITERIA 

To further evaluate the computer system and file organization 
proposed, one must consider a set of performance and cost factors. 
The performance criteria that should be considered are recall ratio, 
precision ratio, coverage and response time and of these the most 
important factors are recall and precision. The reeall ratio is 
defined as: 

number of relevant documents retrieved by the system 
total number of relevant documents contained in the system 

and the precision ratio is defined as: 

number of relevant document's retrieved by die system 
total number of documents retrieved by the system 

Although response time is important it must be a secondary con- 
sideration to precision and recall. Finally tlie coverage that tbe 
system provides is important because presumably, a user will not 
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CONCEPTUAL EDP SYSTEM 



even approacli the system unless he ieels that its coverage is 
such that it will be able to contribute to satisfying his infor- 
mation needs. However, comprehensiveness of coverage is really 
only of concern to the user who requires high recall and the 
requestor with a lov\7 recall requirement on the other hand, may 
not be particularly concerned about coverage. 

The cost factors that have to be considered are the computer 
time used in searching and the frequency of use of the system. 

In machine terms the computer time used v\7ill depend on the size 
of the data base, the type of search (e.g., serial, inverted) 
and the numlDer of records found. One point to note here is that 
the time taken in search with an inverted file system increases 
in almost direct proportion to the number of recorcb in the query, 
whereas the effect of each additional record on speed of search 
in a sequential system is normally less than the effect of the 
inverted system. If the frequency of use of the system is great 
the net overall cost of the system goes down. It should be noted 
here that if too many users are allowed access to the system, it 
may become saturated and give slow turnaround time thereby dis- 
couraging potential users. By considering the above criteria, 
the system chosen will likely be more compatible with the user's 
needs . 

F. ADDITIONAL STUDIES REQUIRED 

The system presented is by no means specific to the tailored 
needs of NAVELEX. Additional research should be done to determine 
if a nevN? file design would be required in the future. Tliis may 
be accomplished by questioning the users on tlie expected frequency 
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of file inquiries or what new capability should be developed to 
meet future needs. It should be noted that with each new capa- 
bility some amount of complexity is going to be introduced in 
maintaining any complex file design. Another method of review- 
ing and projecting new demands on the system is to do a statis- 
tical analysis of the frequency that data fields are accessed to 
ascertain if the present file system needs to be modified. Final 
ly, a study should be initiated to determine if NAVELEX should 
buy pre-packed routines for their system or do their own in-house 
software development. There are trade-offs with this approach 
namely, if a pre-packaged routine is purchased, the user doesn't 
have to be proficient in the software language. On the other 
hand modification of the programs by the user may be very diffi- 
eult. Obviously more studies are required before NAVELEX actu- 
ally acquires a data base management system and it's associated 
operating system. It is hoped that the procedures described in 
this paper will provide useful guidance to NA\/ELEX in the develop 
ment of automated data processing systems. 
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